Since early computer systems performed only simple tasks, it was unnecessary for them to include more than one input/output unit (I/O unit). For this reason, computer systems such as the EDVAC device of 1948 contained only a single I/O unit. The I/O unit was merely the mechanism used by the computer system to communicate with the outside world. Since these early computer systems required a relatively small amount of information, the I/O unit could be controlled by the central processing unit (CPU) itself. As time passed, the complex tasks performed by computer systems required access to more and more information. Direct control of the I/O unit by the CPU was no longer practical.
In 1959, Univac Corporation introduced its LARC computer system. The LARC computer system included an input/output controller (IOC) which was itself a genuine computer. The IOC was used to handle the flow of information to and from the outside world, thereby reducing the work required of the CPU. While the IOC controlled up to eight I/O channels, modern day computer systems usually include a single I/O controller for each I/O channel. These I/O controllers are called input/output processors (IOPs). Similar to the IOC of the LARC computer system, IOPs are computer systems unto themselves. Each IOP is responsible for handling the information flow between a particular external device (i.e., "the outside world") and the computer system.
The wide use of IOPs has greatly improved the overall performance of today's computer systems. Computer systems can now communicate with a variety of external devices without overly burdening the CPU. Examples of devices which can be connected via IOPs include: terminals, magnetic storage units, optical storage devices, programmable workstations, and other computer systems. To the computer system, each of these external devices represents a resource that can be used to perform a specified task. In many cases, the task to be performed can be accomplished by the external devices without extensive intervention on the part of the CPU. This, of course, greatly reduces the work required of the CPU.
Since today's multimedia applications typically require extensive access to audio and video information, they are illustrative of the potential performance advantage of IOPs. The amount of data necessary to present a user with audio and video information is enormous. Hence, tremendous performance savings are possible in theory by allowing a multimedia application associated with an IOP to bypass the main CPU and access information from another IOP directly. Inherent in this noninterventionist approach, however, is the problem of securing information and resources. Allowing external devices to connect at will makes unauthorized use of system resources a real problem. Without some type of security, the users associated with the various external devices may attempt to gain access to personal or otherwise sensitive information. This problem is magnified when one considers that the computer system, the various IOPs, and the attached external devices may be owned or manufactured by different parties. In this later, worse case scenario, rogue IOPs may actually be introduced into the computer system to facilitate the unauthorized use of system resources (i.e., to steal information).
Solutions to this problem invariably involve some CPU intervention. Thus a balance is struck between efficiency and security. A computer system which is more secure tends to be less efficient while a computer system which is very efficient tends to be less secure. This tradeoff stems from the fact that highly secure computer systems must include a means (i.e., authorization means) to allow or disallow access to system resources. While authorization means do provide for increased security, they also create expensive performance overhead which reduces overall system efficiency. Hence, computer system designers are always attempting to design systems that are efficient yet secure (i.e., "to have their cake and eat it too").
A solution to a related security problem is an authorization model called Kerberos. Kerberos was jointly developed by Digital Equipment Corporation, International Business Machines Corporation (IBM), and the Massachusetts Institute of Technology (MIT) for use on an MIT campus-wide computer network.
Kerberos uses a system of messages and keys to deal with the security problem. To obtain information from a server device, a client device must first request authorization from a Kerberos server. This action triggers a series of encrypted messages which are sent by the Kerberos server to the client and server devices and from the client device to the server device. Eventually, the client device is able to connect to the server device.
Although Kerberos is an illustrative solution to a related security problem, Kerberos was not designed to solve the problem of rogue IOPs. Further, the Kerberos authentication model is itself flawed in many respects. One problem with the Kerberos model is its inherent complexity. Each device that wishes to participate in the authentication scheme must first register itself with the appropriate Kerberos server. To accomplish this, the subject device must first have knowledge about the resources controlled by particular Kerberos servers and then register with the appropriate Kerberos server or servers. The registration process is itself complex in that each Kerberos server must allocate a unique encryption key to each device. If multiple Kerberos servers are involved, each device must understand what key is to be used for what resources.
The inherent complexity of the Kerberos model is exacerbated by the model's dependence on encryption. The Kerberos model would simply not work without its elaborate system of key based encryption. Each device must support shared secret key cryptography and understand how the keys are used within the Kerberos protocol. When a Kerberos client device receives an authorization request, it must know what key is to be associated with the client device, what key is to be associated with the server device, and what unique key can be used to communicate between the two devices. When the client device receives this information from the Kerberos server, it must understand that it needs to use its key to decrypt the message sent to it, that it cannot decrypt the message sent from the Kerberos server to the server device, and that it must use the new key to encrypt its response message to the server device. When the server device finally gets the message from the client device, it must understand that it needs to use its shared secret key to access the new key and that it must use the new key to access the information from the client device. This complexity is compounded when one remembers that each device can be involved in multiple connections.
Yet another problem with the Kerbero's model and generally the noninterventionist approach, is the lack of resource information available to client devices. Beyond the need to understand the location of system resources for registration purposes, each client must expressly inform the Kerberos server of the name of the particular server device with which it wishes to communicate. The Kerberos model does not contemplate authorization on an entity to information basis. In other words, a client device cannot simply say "I want access to information X." A Kerberos server would reject such a request as lacking the appropriate server address information.